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(57) A computer network is provided comprising a 
plurality of computers (1 ,2) and a server (4) connected 
via a communications network (3). Each of the plurality 
of computers (1 ,2) contains an accountancy system (5) 
for storing records indicative of mutual obligations be- 
tween companies. The plurality of computers (1 ,2) also 
each contain the invoice processing module (9) for mon- 
itoring the amendment of records within the accountan- 
cy system (5). Whenever an amendment is made to the 



records of the accountancy system (5) the invoice 
processing module (9) causes a message to be gener- 
ated that is sent via the communication network (3) and 
the server (4) to a selected one of the other computers 
of the plurality of computers (1 ,2) associated with a com- 
pany to which the mutual obligation of the record relates. 
On receipt of a message an invoice processing module 
(9) of that computer causes the accountancy system (5) 
within that computer to be updated to reflect the change 
of the mutual obligation. 
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Description 

[0001] The present application relates to computer 
apparatus for monitoring and updating the content of ac- 
countancy records within computerised accountancy 
systems. In particular the present invention concerns 
apparatus for monitoring and updating the content of 
computerised accountancy systems via a computer net- 
work. 

[0002] In conventional accountancy systems when an 
invoice is raised a hard copy of the invoice is printed out 
and then dispatched to the other party to a contract. 
When the hard copy invoice is received by a company, 
the content of the hard copy invoice is checked to de- 
termine whether it accurately reflects the contract into 
which the company has entered and if the information 
on the invoice is considered to be acceptable, an entry 
is then made into the accounting system of that compa- 
ny to reflect acceptance of liability for the invoice. 
[0003] When payment of an invoice is made a record 
is updated within an accountancy system indicating that 
liability corresponding to the payment has been dis- 
charged and a cheque or other form of payment has 
been sentto honourthe invoice. When acheque or other 
form of payment is received by a company it is matched 
to an invoice within their accountancy system and the 
records of that accountancy system are then amended 
to reflect the fact that payment has been received. 
[0004] A problem with known computerised account- 
ancy systems is that the repeated matching and check- 
ing of paper invoices and subsequent manual entry of 
data into accountancy systems is time consuming. How- 
ever, the checking involved is considered necessary in 
order to maintain the integrity of accountancy records 
and to ensure that such records accurately reflect the 
liabilities accepted by a company. 
[0005] In accordance with one aspect of the present 
invention there is provided a network computer system 
comprising a plurality of computers each having stored 
therein a computerised accountancy system, and a 
communications network arranged to facilitate the dis- 
patch of data between said plurality of computers, char- 
acterised in that each of said plurality of computers fur- 
ther comprises: 

monitoring means for monitoring the input and up- 
dating of records within said accountancy system of said 
computer; message output means for outputting to said 
communications network on the basis of the monitoring 
by said monitoring means data indicative of records in- 
put or updated in said accountancy system and account- 
ancy update means for receiving data from said com- 
munications network, said accountancy update means 
being arranged to utilize said data output by said output 
means to cause the generation or update of records 
within said accountancy system. 
[0006] In accordance with this aspect of the present 
invention as the content of the input or update of records 
from an accountancy system is utilized to cause the gen- 



eration or update of records within another accountancy 
system of the computer network, a means is provided 
by which when an invoice is raised or paid, data relating 
to the invoice needs only to be input into the computer 
5 network once by a sender thus reducing the necessity 
to re-input data and therefore the likelihood of error. 
[0007] In an embodiment of the present invention by 
arranging the accountancy updating to require external 
manual input of confirmation that the update of an ac- 
countancy record, a means is provided to maintain the 
integrity of the accountancy system. 
[0008] Further objects and embodiments of the 
present invention will become apparent with reference 
to the following description and drawings in which: 

Figure 1 is a schematic block diagram of a network 
of computers embodying the present invention; 

Figure 2 is a schematic block diagram of an exem- 
plary conventional accountancy system; 

Figure 3 is a schematic block diagram of an exem- 
plary data structure for storing data within an order 
processing database; 

Figure 4 is a schematic block diagram of a data 
structure for storing data within a sales ledger da- 
tabase, debtor ledger database, purchase ledger 
database or creditor's ledger database; 

Figure 5 is a schematic block diagram of the inter- 
action between a conversion module and an invoice 
processing module in accordance with the present 
invention; 

Figure 6 is a schematic block diagram of a server 
in accordance with an embodiment of the present 
invention; 

Figure 7 is a flow diagram of the processing of a 
control module of an invoice processing module; 

Figure 8 is a flow diagram of the processing of the 
control module following a determination that a re- 
view the content of account databases of an ac- 
countancy system is required; 

Figure 9 is a schematic block diagram of a data 
structure for a message generated by a message 
generation module; 

Figure 1 0 is a block diagram of a data structure for 
a remittance message; 

Figure 11 is a schematic flow diagram of the 
processing of the control module following receipt 
of a message indicative of the raising of an invoice; 
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Figure 1 2 is a flow diagram of the processing of the 
control module following receipt of a message in- 
dicative of the payment of an invoice; 

Figure 1 3 is a flow diagram of the processing of the 
control module following a determination that a 
statement has been requested; 

Figure 1 4 is an exemplary data structure for a state- 
ment request message; 

Figure 15 is a flow diagram of the processing of a 
server in accordance with an embodiment of the 
present invention; and 

Figure 1 6 is an exemplary block diagram of a data 
structure for a statement generated by a server. 

[0009] Figure 1 is a block diagram of a network of 
computers embodying the present invention. The net- 
work comprises a plurality of conventional computers 
1 ,2 located at geographically separate locations within 
offices of different companies or departments. The plu- 
rality of computers 1 ,2 are connected to one another via 
a communications network 3 such as the Internet. A 
server 4 is also connected to the plurality of computers 
1 ,2 via the communications network 3. 
[0010] In accordance with this embodiment, each of 
the computers, 1 ,2 has stored therein an accountancy 
system 5 comprising a conventional accountancy sys- 
tem such as Sageline 50. Sageline 100 or The Great 
Plains Accountancy System. Connected to the account- 
ancy system 5 is a conversion module 7 for converting 
the accountancy records stored within the accountancy 
system 5 from the format specific to that accountancy 
system into a standard format of record. In this embod- 
iment, the conversion module 7 is arranged to convert 
format specific records with an accountancy system 5 
into the format defined by the open database connec- 
tivity standard. 

[001 1] Additionally, within each of the computers 1 ,2 
connected to the conversion module 7 is an invoice 
processing module 9 for monitoring and updating the 
content of the accountancy system 5. The invoice 
processing module 9 itself connected to a banking mod- 
ule 1 1 for obtaining bank account data from a bank (not 
shown) via the communications network 3. 
[001 2] Stored with in the server 4 is a server process- 
ing module 1 5 for processing data received via the com- 
munication network 3 and for outputting data to the com- 
munications network 3. Also stored within the server 4 
are an invoice database 17 and a remittance database 
19. 

[0013] In use the invoice processing modules 9 of the 
plurality of computers 1 ,2 monitor the entry of data into 
the records of the accounting system 5 within their re- 
spective computers 1 ,2. When changes to the records 
of accountancy system 5 indicative of the raising of a 



new sales invoice or payment of an invoice are detected 
the invoice processing module 9 of the computer within 
which the accountancy system 5 is located causes data 
which would in a conventional accountancy system be 

5 printed out as a sales invoice or payment advice note to 
be converted utilizing the conversion module 7 into a 
message for dispatch via the communications network 
3. In this embodiment the messages comprise data in 
XML (Extendable Mark Up Language) which are then 

10 dispatched via the communications network 3 to the 
server 4, where a copy of the message is stored in the 
invoice database 1 7 or the remittance database 1 9. 
[001 4] A further copy of the message in XML is then 
sent from the server 4 to the computer of the company 

15 to which the invoice or payment relates. The invoice 
processing module 9 of that computer then causes the 
received message to be converted utilizing the conver- 
sion module 7from XML intotheformat of record utilized 
by the accountancy system 5 of that computer. The in - 

20 voice processing module 9 then causes the accountan- 
cy system 5 of the computer to be updated to reflect the 
acceptance of invoice or payment subject to confirma- 
tion by a user. 

[001 5] The provision of separate conversion modules 
25 7 and invoice processing modules 9 within each of the 
computers of the network enables the update of ac- 
countancy records to occur regardless of the actual for- 
mat of records stored within the individual accountancy 
systems since data of a specific format is transmitted 
30 via the communications network 3 between the comput- 
ers of the network 1 .2 and the server 4 which is entirely 
independent of any particular form of storage within the 
accounting systems 5. 

[001 6] At any time a user may input a request into the 
35 invoice processing module 9 to obtain a statement of 
invoices and remittances relating to an individual cus- 
tomerfor a defined time period. This causes the invoice 
processing module 9 to generate a statement request 
message that is sent to the server 4 via the communi- 
40 cation network 3. On receipt of a statement request 
message the server processing module 1 5 of the server 
4 causes a statement to be generated from the copies 
of messages stored as records within the invoice data- 
base 17 and the remittance database 19 as will be de- 
45 scribed in detail later. The generated statement is then 
sent from the server 4 via the communications network 
3 to the computer from where a request originated. De- 
tails of the transactions between a company and their 
customers may then be displayed. 
50 [0017] In this way since details of invoices are readily 
accessible some of the difficulties of confirming the ve- 
racity of accounts are thereby avoided. The system also 
provides a simple means by which duplicate invoices 
may be generated since data representative of the con- 
55 tent of invoices is directly available. Additionally, since 
the server 4 is separate from the plurality of computers 
1 ,2, the server 4 acts as a backup system for the storing 
of financial data. 
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[0018] Prior to describing in detail the processing of 
data by the invoice processing module 9 and the server 
processing module 15, an exemplary accountancy sys- 
tem for storing and processing accountancy records will 
now be described with reference to Figures 2 to 4. 
[001 9] Figure 2 is a schematic block diagram of a con- 
ventional accountancy system such as Sageline 50, 
Sageline 100 or Great Plains Accountancy System. 
Conventional accountancy systems comprise: a data- 
base management programme 20 and a plurality of 
record databases 22. The database management pro- 
gram 20 enables data to be entered, processed and re- 
trieved from the plurality of databases 22. 
[0020] In a conventional accounting system the plu- 
rality of databases 22 normally comprise a client data- 
base 24 for storing records including details about cus- 
tomers for example customers' names, addresses and 
telephone numbers, an order processing database 26 
for storing records including details of orders received; 
a sales ledger database 28 for storing records of sales 
invoices raised; a debtors ledger database 30 for storing 
records of sales invoices which haveyetto be honoured; 
a purchase ledger database 32 for storing records of 
sales invoices received for purchases made; a creditors 
ledger database 34 for storing records of sales invoices 
received which have yet to be honoured and a cash 
ledger database 36 for storing details about the current 
amount of money within a company's bank accounts. 
[0021] Figure 3 is a schematic block diagram of an 
exemplary data structure for storing data within an order 
processing database 26 of an accountancy system 5. 
Records within an order processing database 26 ordi- 
narily comprise a seller's order ID number 40 identifying 
an order for a seller's records; a buyer order number 42 
comprising a number identifying the request for items 
made by a buyer for the buyer's records and one or more 
item records 44 each containing data identifying the 
products ordered, the number of products ordered and 
price data such as the cost for each product and the rate 
at which tax is levied on the product. 
[0022] Figure 4 is a schematic block diagram of a data 
structure for storing data within a sales ledger database 
28, a debtors ledger database 30, a purchase ledger da- 
tabase 32 and a creditors ledger database 34. Records 
in these databases comprise an invoice identification 
number 50 for identifying the invoice which caused the 
entry of the record onto the accountancy system; date 
data 52 comprising data identifying the date when an 
invoice was raised together with a tax point date; client 
identification data 54 comprising data identifying the cli- 
ent record within the client database 24 corresponding 
to the client to which an invoice relates, a buyer order 
number 56; a seller order number 58; one or more item 
records 60 each containing data identifying the products 
ordered, the number of products ordered and price data 
such as the cost for each product and the rate at which 
tax is levied on the product; and a price record 62 con- 
taining details of the total amount and total amount of 



tax due on the invoice; and text data 64 being a text 
description of the goods or services for which an invoice 
was raised. 

[0023] For records within the sales ledger database 
5 28 and debtors ledger database, the buyer order 
number 56, seller order number 58 and item records 60 
normally will correspond to the buyer order number 42, 
seller order ID 40 and item records 44 of an order pre- 
viously present in the order processing database 26 in- 
fo dicating that invoices have been raised in response to 
orders represented by the records in the order process- 
ing database 26. For records within the purchase ledger 
database 32 and credit ledger database 34, the buyer 
order number 56, seller order number 58 and item 
15 records 60 will normally correspond to the buyer order 
number 42, seller order ID 40 and item records 44 of an 
order processing record on an order processing data- 
base 26 of the accountancy system 5 of the supplier 
from whom invoices have been received. 
20 [0024] In a conventional accounting system when an 
order is received an order record is entered using the 
database management program 20 into the order 
processing database 26 which relates the items identi- 
fied by the item records 44 to a client within the client 
25 database 24. When an invoice is then raised for an or- 
der, records are generated within the sales ledger data- 
base 28 and the debtor's ledger database 30 identifying 
that a sale has been made and liability has been in- 
curred by the purchaser. When payment of an invoice 
30 is received, after payment has been confirmed, the 
record on the debtor's ledger database 30 is updated to 
indicate the honouring of the debt and the cash ledger 
36 is amended to account for the payment. 
[0025] In a conventional accountancy system when 
35 an invoice is received from another company, records 
are created within the purchase ledger 32 and creditors 
ledger 34 and information from the invoice is then man- 
ually entered into the accountancy system to complete 
the new records. When payment of the invoice in the 
40 purchase ledger 32 is made the copy of a record for that 
invoice in the creditor's ledger 34 updated as being paid 
and the cash ledger 36 is adjusted to account for the 
making of the payment. 

[0026] The applicant has appreciated that whilst in- 
45 tended to reflect opposite sides of the same transac- 
tions, conventional accountancy systems require re- 
peated entry of the same data about an invoice giving 
rise to the need for additional labour and also additional 
opportunities for error. The applicant has further realised 
50 that the insistence on independent data entry largely 
arises from the need to ensure that the integrity of an 
accountancy system is maintained. In the present inven- 
tion a means is provided to reconcile these two require- 
ments and thus provide an accountancy system which 
55 reduces repeated data entry whilst providing means to 
ensure that accountancy records accurately reflect the 
liabilities accepted by an organisation. 
[0027] In this embodiment, this is achieved by the in- 
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teraction of the conversion module 7 and invoice 
processing module 9 with the accountancy system 5 
within a computer 1 and with other conversion modules 
7 and invoice processing modules 9 via the communi- 
cations network 3 and server 4, which will now be de- 
scribed with reference to Figures 5 to 16. 
[0028] Figure 5 is a schematic block diagram showing 
in detail the interaction between the conversion module 
7 and the invoice processing module 9 in a computer 1 ; 
2. In this embodiment, the conversion module 7 com- 
prises a conventional conversion module for generating 
in a standard format copies of records stored in the spe- 
cific format of records in an accountancy system 5. In 
this embodiment the specific format comprises the for- 
mat defined as the open database connectivity format 
which enables accountancy data from one accountancy 
system to be transferred to other financial system pro- 
grams. 

[0029] The conversion module 7 comprises two parts, 
an open database connectivity interface 70 and an open 
database connectivity record database 72. The open 
database connectivity interface 70 is connected to the 
accountancy system 5 (not shown in Figure 5) and the 
open database connectivity record database 72 and is 
arranged to generate copies of records in a standard 
format from records in the system specific format of the 
accountancy system 5. The standard format records are 
then stored within the open database connectivity 
record database 72. The open database connectivity in- 
terface 70 is also arranged to convert records stored 
within the open database connectivity record database 
72 stored in the open database connectivity record for- 
mat into a format for storage within the accountancy sys- 
tem 5. 

[0030] The invoice processing module 9 in accord- 
ance with this embodiment of the present invention com- 
prises a control module 90 that is connected to both the 
open database connectivity interface 70 and the open 
database connectivity record database 72 of the con- 
version module 7. The control module 90 is also con- 
nected to a clock 91, a statement processing module 
92, a message receipt buffer 93, a message generation 
module 94 and to the banking module 11 (not shown in 
Figure 5). The message receipt buffer 93 is arranged to 
receive data from the communications network 3 (not 
shown in Figure 5) and is also indirectly connected to 
the open database connectivity record database 72 of 
the conversion module 7 via a message conversion 
module 95. The message receipt buffer 93 is also con- 
nected to the statement processing module 92. The 
message generation module 94 in addition to being con- 
nected to the control module 90 is connected to a com- 
pany details record 96 storing data about the company, 
the open database connectivity record database 72 of 
the conversion module 7 and is also arranged to output 
data to the communication network 3 (not shown in Fig- 
ure 5). 

[0031] As will be described in greater detail later the 



control module 90 is arranged to initiate the dispatch of 
data in response to the detection of the input of a new 
record into the sales ledger database 28 orthe updating 
of a record in the creditors database 34 of an account- 

5 ancy system 5; to coordinate the automatic update of 
the accountancy system 5 in response to received data 
from the communications network 3; and to enable 
statements of account to be viewed by a user inputting 
instructions into the statement processing module 92. 

10 [0032] In this embodimentthe initiation of the dispatch 
of data is achieved by the control module 90 being ar- 
ranged to receive a clock signal from the clock 91 . Pe- 
riodically the control module 90 then instructs the open 
database connectivity interface 70 of the conversion 

15 module 7 to retrieve records from the accountancy sys- 
tem 5 (not shown in Figure 5) reflecting the issue of new 
sales invoices which are then stored in the open data- 
base connectivity record database 72. When the control 
module 90 receives from the open database connectiv- 

20 ity record database 72 of the conversion module 7 a sig- 
nal indicating that the records have been retrieved this 
then causes the control module 90 to invoke the mes- 
sage generation module 94 which generates utilizing 
data stored within the open database connectivity 

25 record and the company details record database 96 an 
XML message which is then dispatched via the commu- 
nication network 3 to the server 4. The dispatched mes- 
sage then causes records with server 4 to be updated 
and for a further XML message to be dispatched to the 

30 computer 2 of the company or department to which an 
invoice or payment relates so that the accountancy sys- 
tem 5 of that company or department may be automat- 
ically updated. 

[0033] When an XML message is received from the 
35 communications network 3 it is stored within the mes- 
sage receipt buffer 93 which causes a signal to be sent 
to the control module 90. The control module 90 then 
causes the message conversion module 95 to convert 
the XML message stored within the message receipt 
40 buffer 93 into an open database connectivity record 
which is then stored in the open database connectivity 
record database 72 of the conversion module 7 which 
is then used to cause the records of the accountancy 
system 5 to be updated as will be described in detail 
45 later. 

[0034] The statement processing module 92 is ar- 
ranged on receipt of an input signal from a user via an 
input device such as a keyboard or mouse (not shown) 
to cause a signal to be sent via the control module 90 

50 to the message generation module 94 which causes a 
statement request to be sent via the communications 
network3 to the server 4 (not shown in Figure 5). When 
statement data is dispatched to the computer this is re- 
ceived from the communications network 3 by the mes- 

55 sage buffer 93 which passes the data to the statement 
processing module 92 for display as will also be de- 
scribed in detail later. 

[0035] The content and processing of a server 4 ar- 
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ranged to receive messages generated by the invoice 
processing models 9 of the plurality of computers 1,2 
via a communications network 3 will now be described. 
[0036] Figure 6 is a schematic block diagram of a 
server 4 in accordance with this embodiment which has 
stored therein a server processing module 15, an in- 
voice database 1 7 and remittance database 1 9. The 
server processing module 15 comprises a message 
buffer 1 00, a database control module 1 02, a message 
output module 1 04, and a user database 1 06. The mes- 
sage buffer 100 is arranged to receive XML data from 
the communications network 3 (not shown in Figure 6) 
and is also connected to the invoice database 17 the 
database control module 102 and the remittance data- 
base 19. The database control module 1 02 is also con- 
nected to the invoice database 1 7, the remittance data- 
base 19, the user database 106 and the message output 
module 104. The message output module is itself also 
connected to the invoice database 17 and the remit- 
tance database 1 9 and is arranged to output data to the 
communications network 3. 

[0037] When XML data is received from the commu- 
nications network 3 it is stored in the message buffer 
1 00 wh ich causes a signal to be sent to the control mod- 
ule 1 02. If the XML data received by the message buffer 
100 relates to the updating of records within an account- 
ancy system 5 the database control module 102 then 
causes the data stored within the message buffer 100 
to be stored as a record within the invoice database 17 
orthe remittance database 1 9 depending upon whether 
the message relates to the raising of invoices or pay- 
ment of invoices. The database control module 102 then 
utilizes the data stored within the user database 1 06 to 
dispatch a further XML message comprising a copy of 
the record newly stored within either the invoice data- 
base 17 or the remittance database 19 to the invoice 
processing module of the computer corresponding to 
the other party to the invoice or payment as will be de- 
scribed in detail later. 

[0038] If XML data received by the message buffer 
100 relates to a requestforthe generation of a statement 
the database control module 1 02 then causes the mes- 
sage output module 104 to generate a statement com- 
prising XML data representative of copies of records 
stored within the invoice database 17 and remittance 
database 19 which is then dispatched to the invoice 
processing module 9 from where the request for a state- 
ment originated as will also be described in detail later. 
[0039] Processing of the invoice processing module 
9 of the plurality of computers 1 , 2 will now be described 
in detail with reference to Figures 7 to 13. 
[0040] Figure 7 is a flow diagram of the processing of 
the control module 90 of the invoice processing module 
9. When the processing of the control module 90 begins 
the control module 90 initially determines (S1) whether 
the time indicated by the clock 91 indicates that a deter- 
mination of whether the content of the accountancy sys- 
tem 5 of the computer within which the invoice process- 



ing module 9 is present is required. 
[0041] If the time indicated by the clock 91 indicates 
that a determination of whether any records have been 
entered in the sales ledger database 28 or records with- 
5 in the creditors ledger database 34 have been updated 
in the accountancy system 5 is required the control mod- 
ule 90 then (S2) causes recently entered or updated 
records within the accountancy system 5 to be identified 
and converted by the Open Database Connectivity in- 
10 terface 70 (hereinafter referred to as ODBC interface 
70) and the message conversion module 95 and then 
dispatched to the server 4 as will be described in detail 
with reference to Figures 8 to 1 0 later. 
[0042] If the signal received by the clock 91 does not 
15 indicate that the review of the content of the databases 
22 of the accountancy system 5 is required or after such 
a review has been conducted and any required messag- 
es have been dispatched to the server 4, the control 
module 90 then (S3) determines whether a signal has 
20 been received from the message receipt buffer 93 indi- 
cating that a message indicative of a new invoice being 
raised has been received from the communication net- 
work 3. If the control module 90 determines that such a 
message has been received from the message receipt 
25 buffer 93 the control module 90 then causes (S4) the 
received message to update the databases 22 of the 
accountancy system 5 as will be described in detail with 
reference to Figure 11 later. 

[0043] After a control module 90 has determined 
30 whether a message indicative of a new invoice has been 
received by the message receipt buffer 93 and caused 
the accountancy system 5 to be updated if necessary, 
the control module 90 then determines whether a signal 
has been received from the message receipt buffer 93 
35 indicating that a message indicative of the receipt of the 
making of a payment has been received (S5). If a signal 
is received from the message receipt buffer 93 which is 
indicative of receipt of a message indicative of a pay- 
ment, the control module 90 then causes (S6) the ac- 
40 countancy system 5 to be updated to account for the 
payment as will be described in detail with reference to 
Figure 12 later. 

[0044] After the control module 90 has determined 
(S5) that the message receipt buffer 93 has not received 
45 data indicative of the making of a payment or has up- 
dated the accountancy system 5 if such a message has 
been received, the control module 90 then determines 
(S7) whether a statement has been requested utilizing 
the statement processing module 92. If such a request 
50 has been received by the statement processing module 
92 the control module 90 causes the statement process- 
ing module 92 to obtain and display statement informa- 
tion in accordance with the statement request (S8) as 
will be described in detail with reference to Figure 13. 
55 After obtaining and displaying requested statement in- 
formation or if the control module 90 determines that no 
such statement has been requested the processing of 
the control module 90 comes to an end. 
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[0045] Figure 8 is a flow diagram of the processing of 
the control module 90 following the determination (S1) 
that a review of the content of the account databases 
22 of the accountancy system 5 is required. 
[0046] Initially (S20) the control module 90 sends to 
the Open Database Connectivity Interface 70 (hereinaf- 
ter referred to as the ODBC interface 70) of the conver- 
sion module 7 an instruction to retrieve from the sales 
ledger database 28 the records in the sales ledger da- 
tabase 28 which have been created since the control 
module 90 last requested that such records were re- 
trieved, together with any client records within the client 
database 24 corresponding to the client identification 
number 54 of those records within the sales ledger da- 
tabase 28. This causes the ODBC interface 70 to create 
copies of the req uested records from the client database 
24 and the sales ledger database 28 which are then 
stored within the Open Database Connectivity record 
database 72 (hereinafter referred to as the ODBC 
record database 72) in open database connectivity for- 
mat. 

[0047] When the control module 90 has determined 
that all the requested records have been copied into the 
ODBC record database 72 the control module 90 then 
invokes (S21) the message generation module 94 to 
create and dispatch XML messages corresponding to 
the retrieved records in the ODBC record database 72 
to the server 4 via the communications network 3. 
[0048] Figure 9 is a block diagram of a data structure 
for a message generated by the message generation 
module 94. 

[0049] In this embodiment, the message comprises 
XML data comprising: a unique reference number 110 
generated automatically by the message generation 
module 94; date data 112, a buyer order number, 114 
and a seller order number 1 1 6 corresponding to the date 
data 52, a buyer order number 56 and a seller order 
number 58 of a record retrieved from the sales ledger 
database 28; a buyer record 118 corresponding to the 
client record retrieved from the client database 24 iden- 
tified by the client identification number 54 of the record 
retrieved from the sales ledger database 28; a seller 
record being a copy of the data contained within the 
company details record 96 of the invoice processing 
module 9 and a number of item records 122, a price 
record 1 24 and text data 1 26 corresponding to the item 
records 60, price record 62 and text data 64 as con- 
tained within the record retrieved from the sales ledger 
database 28. 

[0050] When an XML message has been generated 
for a record from the sales ledger database 28 stored 
within the ODBC record database 72 the message gen- 
eration module 94 causes the newly generated XML 
message to be dispatched to the server 4 via the com- 
munications network 3. The copy of the record within 
the ODBC record database 72 is then deleted and fur- 
ther messages are generated by the message genera- 
tion module 94 in respect of each of the other records 



retrieved until no further records remain in the ODBC 
record database 72. 

[0051] When the control module 90 determines that 
no records retrieved from the sales ledger database 28 

5 remain within the ODBC record database 72 the control 
module 90 then (S22) causes a signal to be sent to the 
ODBC interface 70 to request retrieval from the account- 
ancy system 5 records from within the purchase ledger 
database 32 indicative of purchase invoice records 

10 which have been updated within the creditors ledger da- 
tabase 34, since the last request for retrieval of payment 
invoices together with client records from the client da- 
tabase 44 corresponding to the client records identified 
by the client identification number 54 of the records re- 
's trieved from the purchase ledger database 32. 

[0052] When all of the required records from the pur- 
chase ledger database 32 and associated records from 
within the client database 24 have been copied from the 
accountancy system 5 into the ODBC record database 

20 72 the control module 90 then causes the message gen- 
eration module 94 to generate and dispatch (S23) for 
each of the copies of the client records within the ODBC 
record database 72 a remittance message. 
[0053] Figure 10 is a schematic block diagram of a 

25 data structure for a remittance message. In this embod- 
iment a remittance message comprises XML data com- 
prising: a uniquely generated reference number 130 
generated by the message generation module 94; date 
data corresponding to the time indicated by the clock 

30 91 ; a buyer record 134 corresponding to a copy of the 
company details record 96 from the invoice processing 
module 9; a seller record 136 comprising a copy of the 
client record within the client record database 24 corre- 
sponding to the client ID number 54 of the one of the 

35 record retrieved from the purchase ledger database 32; 
one or more invoice records 138 corresponding to cop- 
ies of each of the records in the ODBC record database 
72 having a client identification number 54 correspond- 
ing to the client identification number of the client record 

40 included within the message; and a remittance record 
1 40 comprising a total amount paid and a total amount 
of tax determined by summing the corresponding values 
within the price records 124 of each of the invoice 
records 138 within the message. 

45 [0054] When a message of the form illustrated in Fig- 
ure 10 has been generated by the message generation 
module 94 it is then dispatched to the server 4 via the 
communications network 3. The message generation 
module 94 then causes all of the records within the OD- 

50 BC record database 72 which have been incorporated 
into the message dispatched by the message genera- 
tion module 94 to be deleted from the ODBC record da- 
tabase 72 and then generates further messages utilizing 
any remaining records within the ODBC record data- 

55 base 72. When no records remain within the ODBC 
record database 72 this is detected by the control mod- 
ule 90 which then proceeds to determine whether any 
new invoices have been received (S3). 
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[0055] As will be described in detail laterfollowing the 
dispatch of messages created by the message genera- 
tion module 94, these messages are processed by the 
server 4 which causes copies of the messages to be 
stored within the invoice database 1 7 or remittance da- 
tabase 19 of the server 4 and for further messages to 
be dispatched to the computer 2 of the plurality of com- 
puters 1 ,2 of the company or department which an in- 
voice or payment relates which is identical to the mes- 
sage received by the server 4 which then causes the 
accountancy system of the computer 2 to be updated. 
[0056] Figure 11 is a flow diagram of the processing 
of the control module 90 of the invoice processing mod- 
ule 9 following receipt of a message in the format of Fig- 
ure 9, indicative of the raising of an invoice on an ac- 
countancy system 5 of another computer. 
[0057] The control module 90 initially (S40) causes 
the XML message to be passed from the message re- 
ceipt buffer 93 to the message conversion module 95 
which then utilizes the received XML message to gen- 
erate a client record, and an order record in Open Da- 
tabase Connectivity format, which are stored within the 
ODBC record database 72. This is achieved by the mes- 
sage conversion module 95 generating a client record 
corresponding to the seller record 1 20 of the message; 
an order record comprising the seller order number 116, 
buyer order number 114 and the one or more item 
records 122 of the received message. 
[0058] The control module 90 then causes (S41) the 
ODBC interface 70 to attempt to retrieve from the client 
database 24 and order processing database 26 of the 
accountancy system 5 a client record and order record 
corresponding to the client record and order record gen- 
erated by the message conversion module 95. 
[0059] The control module 90 then (S42) determines 
whether such records have been retrieved. If this occurs 
it indicates that the message received by the message 
receipt buffer 93 relates to the raising of an invoice for 
an order for which records exist within the order 
processing database 26 of the accountancy system 5. 
After these records are retrieved the control module 90 
then causes to be displayed to a user data indicative of 
the content of the message received and the retrieved 
order record retrieved from the order precessing data- 
base 26 to enable a user to verify (S44) the content of 
the message received and to authorise the posting of 
invoice data onto the accountancy system 5 of the com- 
puter 2. 

[0060] If a user having reviewed the content of the 
message and compared it with the order data retrieved 
from the order processing database 26 inputs via an in- 
put device (not shown) an authorisation for the posting 
of a new invoice within the accountancy system 5 the 
control module 90 then causes (S45) the message con- 
version module 95 to generate within the ODBC record 
database 72 a record for inclusion within the creditors 
ledger database 34 and purchase ledger database 32 
of the accountancy system 5 comprising the next avail- 



able invoice identification number as an invoice ID 50, 
date data 52 corresponding to the date data 112 of the 
received message; a client identification number 54 cor- 
responding to the client identification number of the cli- 

5 ent record retrieved from the client database 24 and a 
buyer order number 56, seller order number 58, one or 
more item records 60, a price record 62 and text data 
64 corresponding to the buyer order number 114, seller 
order number 1 1 6 ; one or more item records 1 12, price 

10 record 1 24 and text data 1 26 of the received message. 
The control module 90 then causes the ODBC interface 
70 to cause the accountancy system 5 to update the pur- 
chase and creditors ledgers 32,34 by incorporating the 
newly generated records stored within the ODBC record 

15 database 72 to reflect acceptance of the liability indicat- 
ed by the received message. 

[0061] If (S42) no order data or client record corre- 
sponding to a received message can be retrieved from 
the accountancy system 5 or authorisation for the post- 
20 ing of an invoice (S44) is not received by the control 
module 90 causes the data indicated by a received mes- 
sage to be displayed (S46) to a user together with a 
warning. 

[0062] Thus in this way by causing the receipt of a 

25 message indicating the raising of an invoice on one 
computer 1 to generate a corresponding record within 
the accountancy system 5 of another computer 2 a 
means is provided by which the repeated entry of data 
corresponding to the same invoice may be avoided. 

30 However by causing the control module 90 to determine 
firstly whether a message received corresponds to an 
order record within the order processing database 26 of 
an accountancy system 5 and additionally requiring user 
confirmation that records are to be updated, a means is 

35 provided for ensuring that the integrity of an individual 
company's accountancy records can be maintained. 
[0063] Figure 12 is a flow diagram of the processing 
of the control module 90 following a determination of 
whether (S5) the message receipt buffer 93 has re- 

40 ceived an XML message indicative of the making of a 
payment of invoices of the format shown in Figure 10. 
Initially (S60) the control module 90 causes the mes- 
sage conversion module 95 to utilize the XML message 
within the message receipt buffer 93 to generate in 

45 Open Database Connectivity format, a client record cor- 
responding to the content of the buyer record 1 34 of the 
message within the message receipt buffer 93 and one 
or more invoice records corresponding to the one or 
more invoice records corresponding to the one or more 

50 invoice records 1 38 within the XML message. The gen- 
erated client record and invoice records are then stored 
within the ODBC record database 72. 
[0064] The control module 90 then causes the ODBC 
interface 70 to retrieve (S62) from the debtors ledger 

55 database 30 records having seller order numbers 58 
corresponding to the seller order numbers 58 of the in- 
voice records stored within the ODBC record database 
72 together with a client record from the client database 
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24 corresponding to the client record stored within the 
ODBC record database 72. These records are then re- 
trieved from the accountancy system 5 and stored within 
the ODBC record database 72. 

[0065] The control module 90 then (S64) determines 
whether the content of the records retrieved from the 
accountancy system 5 matches the records generated 
by the message conversion module 95 stored within the 
ODBC record database 72. If the records retrieved 
match the records generated by the message conver- 
sion module 95 the control module 90, invokes the bank- 
ing module 11 to obtain bank account data for the ac- 
count into which payment should have been made. The 
control module 90 then causes (S66) the retrieved ac- 
countancy records to be displayed together with the da- 
ta contained within the message buffer 93 and the bank 
account data to a user on a display (not shown). The 
control module 90 then waits (S67) for a user to input 
via an input device (not shown) an indication that the 
posting of the displayed invoices is authorised. If such 
an indication is input by a user the control module 90 
causes (S68) the ODBC interface 70 to update within 
the debtors ledger 30 those records corresponding to 
the records within the ODBC record database 72 and 
amends the cash ledger database 36 to reflect the pay- 
ment indicated within the remittance record 140 of the 
received message. 

[0066] If either the control module 90 determines that 
the invoice records 1 38 within the message received by 
the message receipt buffer 93 do not correspond to 
records within the debtors database or a user indicates 
that posting of an invoice record is not authorised the 
control module 90 causes (S69) to be shown to a user 
on a display (not shown) a warning indicating that liabil- 
ity reflected in the message received by the message 
receipt buffer 93 has not been accepted. 
[0067] Figure 13 is a flow diagram of the processing 
of the control module 90 following a determination (S7) 
that a statement has been requested. Initially the control 
module 90 generates (S80) a statement request to be 
dispatched to the server 4. 

[0068] Figure 14 is a schematic block diagram of an 
exemplary data structure for a statement request mes- 
sage generated by the message generation module 94 
in this embodiment of the present invention. The state- 
ment request message comprises XML data compris- 
ing: a statement request ID number 150 which is a 
uniquely generated identification number generated by 
the control module 90; a buyer record 152 correspond- 
ing to a copy of the company details record 96; a client 
record 1 54 comprising a copy of a client record retrieved 
from the client database 24 is stored within the ODBC 
record database 72; and the time period 156 corre- 
sponding to the time period input to the statement 
processing module 92. 

[0069] In this embodiment, the generation of a state- 
ment request is achieved by the central module 90 ini- 
tially utilizing the input request detailing a client and time 



period input into the statement processing module 92. 
The control module 90 then causes the ODBC interface 
70 to retrieve from the client database 24 of the accou nt- 
ancy system 5 a copy of the client record corresponding 

5 to the client for which a statement has been requested. 
A copy of the requested client record is then generated 
and stored within the ODBC record database 72. The 
control module 90 then causes the message generation 
module 94 to generate an XML message for dispatch to 

10 the server via the communications network 3 utilizing 
the retrieved client record, the company details record 
96 and the time period input into the statement process- 
ing module 92. 

[0070] When a statement request message has been 

15 generated by the message generation module 94 the 
message generation module 94 then causes the state- 
ment request message to be dispatched (S82) to the 
server 4 via the communication network 3. Once a state- 
ment request has been dispatched the control module 

20 90 then (S84) monitors the content of the message re- 
ceipt buffer 93 to determine whether statement data cor- 
responding to the statement request ID 150 of the newly 
dispatched statement request has been received by the 
message receipt buffer 93 when it is determined that a 

25 statement message has been received corresponding 
to the statement request ID 150 of the dispatched re- 
quest has been received by the message receipt buffer 
93, the control module 90 causes the statement mes- 
sage data to be transferred from the message receipt 

30 buffer 93 to the statement processing module 92 and 
displayed (S86) to a user via a display (not shown). The 
processing of the control module 90 then comes to an 
end. 

[0071] The processing of the server 4 following re- 
35 ceipt of messages from invoice processing modules 9 
will now be described. 

[0072] Figure 15 is a flow diagram of the processing 
of the data control module 102 of the server 4 in this 
embodiment of the present invention. Initially, when an 

40 XML message is received by the server 4 from the com- 
munications network 3 it is stored in the message buffer 
1 00. The database control module 1 02 then determines 
(S100) whether the XML message received is a mes- 
sage generated when a new invoice is raised or whether 

45 the XML message is a message generated when a pay- 
ment is recorded within accountancy system 5 or wheth- 
er the XML message relates to a statement request. 
[0073] If the XML message comprises a message 
generated following the raising of a new invoice the con- 

50 trol module 1 02 causes (S1 02) a copy of the message 
to be stored as an invoice record within the invoice da- 
tabase 1 7. If the XML message relates to the making of 
a paymentthe control module 1 02 causes (S1 04) a copy 
of the message to be stored as a payment record within 

55 the remittance database 1 9. 

[0074] After storing a copy of the XML message in ei- 
ther the invoice database 1 7 or the remittance database 
1 9 the database control module 1 02 determines (S1 06) 



9 



17 



EP 1 164 519 A2 



18 



the intended destination for that message. In the case 
of an XML message relating to the raising of a new in- 
voice, this is achieved by the database control module 
1 02 retrieving from the user database 1 06 address data 
corresponding to the buyer record 1 1 8 of the XML mes- 
sage stored within the message buffer 1 00. In the case 
of an XML message generated following the payment 
of an invoice, the database control module 1 02 retrieves 
address data from the user database from a record cor- 
responding to the seller record 136 of the XML message 
stored within a message buffer 1 00. When a destination 
has been determined utilizing the user database 1 06 the 
database control module 102 causes (S108) the con- 
tents of the message buffer 1 00 to be transferred to the 
message output module and be dispatched to the de- 
termined destination. The processing of the database 
control module 102 then comes to an end. 
[0075] Thus in this way by causing XML messages to 
be routed via the server 4 the storage of address data 
for individual customers within the computer systems 
1 ,2 of the individual companies is avoided since all mes- 
sages are dispatched to the server 4 which provides a 
means of central storage of the required address data. 
[0076] If (S1 00) the database control module 1 02 de- 
termines that an XML message received by the mes- 
sage buffer 1 00 relates to a statement request the da- 
tabase control module 1 02 then causes to be generated 
(S110) within the message output module 104 a state- 
ment message which is dispatched to the computer 1 ,2 
from which the statement request originated. 
[0077] Figure 16 is an exemplary block diagram of a 
data structure for a statement generated by the data- 
base control module 102. In this embodiment a state- 
ment comprises XML data comprising: a statement re- 
quest ID 1 60 corresponding to the statement request ID 
150 of the statement request received by the message 
buffer 100; a company record 162 and a client record 
1 64 corresponding to the company record 1 52 and client 
record 154 of the received statement request one or 
more invoice records 166 comprising copies of any in- 
voice records within the invoice database 17 having as 
their buyer record 1 1 8 and seller record 1 20 data corre- 
sponding to the company record 162 client record 164 
of the statement and request one or more payment 
records 1 68 comprising any payment records within the 
remittance database 1 9 having a buyer record 1 34 and 
a seller record 136 corresponding to the company 
record 162 and client record 164 of the statement re- 
quest, where the invoice records 166 and payment 
records 168 all have associated date data 112,132 
which falls within the time period 1 56 of the received re- 
quest. 

[0078] Once a statement has been generated by the 
database control module 102, the generated statement 
is then dispatched back to the computer 1 ,2 from which 
the statement request has been received where it is 
processed by the statement processing module 94 as 
has previously been described. 



[0079] In the previous embodiment computer appara- 
tus has been described in which XML messages indi- 
cating that an invoice has been raised or paid are auto- 
matically dispatched from the server 4 following the re- 

5 ceipt of an XM L message by the server 4 indicating that 
such an action has occurred and that the invoice 
processing modules 9 or each of the computers is ar- 
ranged to monitor for the receipt of messages from the 
server. It will be appreciated that the present invention 

10 is equally applicable to computer networks where data 
indicating whether an invoice has been raised or paid 
on one accountancy system is stored centrally with in- 
dividual computers of the computer network periodically 
accessing the central storageto determine whether data 

15 relating to the update of accountancy records relating to 
the company or departmentforthat computer are stored 
within the central storage system. 
[0080] In a previous embodiment a computer network 
has been described in which the updating of an account- 

20 ancy system 5 in one computer 1 is arranged to cause 
a corresponding update of an accountancy system 5 
within anothercomputer2 whenever an invoice is raised 
or payment is made. It will be appreciated that an invoice 
processing module 9 could be provided which causes 

25 the update of associated accountancy systems 5 when 
other actions occur. Thus for example the invoice 
processing module 9 could be arranged to monitor the 
input of order records within an order processing data- 
base 26 of an accountancy system 5 and upon detection 

30 of the entry of a new order record be arranged to dis- 
patch a message which causes the updating of order 
processing database of an associated accountancy sys- 
tem 5 to reflect the existence of a new order. 
[0081] In such a system since the records of the order 

35 processing database 26 of the computers 1,2, will be 
generated on the basis of one set of data input the 
chances that the records corresponding to the same or- 
der will match and therefore be maximised. If records 
within the order processing database 26 of accountancy 

40 systems 5 of different computers are caused to be up- 
dated in this way the monitoring of amendment of 
records within an order processing database 22 could 
also be provided for so that when the status of an order 
changes, for example, when an order is dispatched the 

45 status of the corresponding order in the accountancy 
system 5 of another computer could also be updated to 
reflect this change of status. Similarly, when an order 
has been received, entry of this information into the or- 
der database could cause the generation of a message 

50 which is sent to the other party to the contract which 
causes the update of the order processing database 22 
of the other parties accountancy system 5 to indicate 
confirmation of receipt of an order. 
[0082] Although in the previous embodiment, upon re- 

55 ceipt of messages indicating the raising of payment of 
an invoice that has been displayed to a user on a com- 
puter the present invention is equally applicable to com- 
puter systems where an accountancy system 5 is stored 
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on a computer which itself is part of a network of com- 
puters within a company or department. In such a sys- 
tem the data required to assess whether a raised invoice 
or payment is to be posted to the accountancy system 
5 could be dispatched into any part of the network. In 
particular, the system could be arranged so that data 
could be automatically dispatched to a computer of the 
network associated with an individual who placed an or- 
der so that posting of different invoices and payments 
to the accountancy system 5 could be authorised by dif- 
ferent individuals. 

[0083] Although in the previous embodiment a de- 
scription has been made of accountancy systems where 
records within different accountancy systems 5 contain 
only information which is also present within an account- 
ancy system where an invoice is originally raised, addi- 
tional information could also be stored when a raised 
invoice is initially authorised for storage within an ac- 
countancy system 5. Thus for example, when requiring 
a user to input an indication that posting of an invoice is 
authorised, the processing module 90 could also re- 
quest a payment date for payment of an invoice. The 
accountancy system 5 could then be arranged to cause 
a newly generated credit record to be deleted automat- 
ically and for a payment to be made via the banking 
module 1 1 at a pre-set time subsequent to the posting 
of an authorised invoice to the accountancy system 5. 
[0084] Additionally, when invoices are posted to an 
accountancy system 5, ordinarily, nominal ledger data 
is added to the invoice data to provide a categorisation 
of the expenditure for accounting purposes. In the em- 
bodiments of the invention, the control module 90 could 
be arranged to request the input of such nominal ledger 
data for inclusion within the records of the accountancy 
system at the time an invoice is posted. Alternatively, a 
database of nominal ledger codes could be provided as- 
sociating nominal ledger codes with the content of item 
records or client records. The control module 90 could 
then be arranged to include automatically within a 
record for storage within the accountancy system, a 
nominal ledger code selected on the basis of the item 
records orclient records retrieved upon receipt of a mes- 
sage indicating the raising of an invoice. 
[0085] Although in the above described embodiments 
reference has been made to the generation of records 
in Open Database Connectivity format and the transmis- 
sion of data and messages comprising XML data, it will 
be appreciated that the present invention is not depend- 
ent upon the selection of a specific format being adopted 
and that any suitable format of data could be selected 
for the generation and transmission of data between ac- 
countancy systems. 

[0086] In the above described embodiments, refer- 
ence has been made to the periodic monitoring of the 
content of an accountancy systems records which is 
then utilized to generate data to cause another account- 
ancy system. It will be appreciated that a system could 
be provided where the manual update of records within 



an accountancy system automatically caused data to be 
immediately dispatched so that a corresponding update 
in another system could be performed. 
[0087] Although the embodiments of the invention de- 
5 scribed with reference to the drawings comprise com- 
puter apparatus and processes performed in computer 
apparatus, the invention also extends to computer pro- 
grams, particularly computer programs on or in a carrier, 
adapted for putting the invention into practice. The pro- 
10 gram may be in the form of source or object code or in 
any other form suitable for use in the implementation of 
the processes according to the invention . The carrier be 
any entity or device capable of carrying the program. 
[0088] For example, the carrier may comprise a stor- 
es age medium, such as a ROM, for example a CD ROM 
or a semiconductor ROM, or a magnetic recording me- 
dium, for example a floppy disc or hard disk. Further, the 
carrier may be a transmissible carrier such as an elec- 
trical or optical signal which may be conveyed via elec- 
20 trical or optical cable or by radio or other means. 

[0089] When a program is embodied in a signal which 
may be conveyed directly by a cable or other device or 
means, the carrier may be constituted by such cable or 
other device or means. 
25 [0090] Alternatively, the carrier may be an integrated 
circuit in which the program is embedded, the integrated 
circuit being adapted for performing, or for use in the 
performance of, the relevant processes. 



1 . A computer network for facilitating the storage and 
amendment of accountancy records indicative of 
35 reciprocal obligations comprising: 

a plurality of computers; and 
a communication network operable to transmit 
data between said plurality of computers, 
40 wherein each of the plurality of computers com- 

prises: 

means for storing and amending account- 
ancy records each indicative of one side of 
45 a reciprocal obligation; 

monitoring means for monitoring the 
amendment of said accounting records 
within said computer, said monitoring 
means being arranged to output data indic- 
50 ative of the content of amended account- 

ancy records to said communications net- 
work; 

receiving means for receiving data indica- 
tive of the content of amended accountan- 
ts cy records stored within other computers 
of said plurality of computers; and 
update means arranged to initiate the 
amendment of accountancy records within 
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a computer utilizing data received by said 
receiving means wherein said update 
means is arranged to initiate amendments 
to accounting records indicative of the oth- 
er side of the reciprocal obligation to that 
indicated by data received by said receiv- 
ing means. 

2. A computer network in accordance with claim 1 , fur- 
ther comprising routing means for routing data in- 
dicative of the content of amended accountancy 
records via said communications network, wherein 
each of said monitoring means of said plurality of 
computers is arranged to output data indicative of 
the content of amended accountancy records to 
said routing means via said communications net- 
work and said routing means is arranged to cause 
said data to be passed to the receiving means of a 
selected computer of said plurality of computers, 
said routing means being arranged to select said 
computer utilizing the received data indicative of the 
content of amended accountancy records output by 
said monitoring means. 

3. A computer network in accordance with claim 2, 
wherein said routing means further comprises stor- 
age means for storing data representative of data 
output to said routing means by said monitoring 
means of said plurality of computers. 

4. A computer network in accordance with claim ^fur- 
ther comprising storage means for storing data in- 
dicative of the content of amended accountancy 
records, said storage means being arranged to out- 
put data indicative of the content of amended ac- 
countancy records in response to a request re- 
ceived from any of said plurality of computers, 
wherein said monitoring means of each of said plu- 
rality of computers is arranged to output data indic- 
ative of the content of amended accountancy 
records to said storage means via said communi- 
cations network, wherein each of said plurality of 
computers further comprises means for outputting 
a request for the output of stored data stored within 
said storage means. 

5. A computer network in accordance with any preced- 
ing claim, wherein each of said plurality of comput- 
ers further comprises input means for inputting data 
indicative of authorisation for the update of account- 
ancy records within said computer, wherein said up- 
date means is arranged only to initiate the amend- 
ment of accountancy records following the receipt 
of data indicative of authorisation of an update input 
via said input means. 

6. A computer network in accordance with claim 5, 
wherein said receiving means is arranged upon re- 



ceipt of data indicative of the content of amended 
accountancy records to retrieve from said means 
for storing accountancy records within said compu- 
ter records corresponding to said amended 

5 records, said plurality of computers each further 
comprising display means for displaying retrieved 
records and data indicative of said amended ac- 
countancy records prior to input of data indicative 
of authorisation of an update of accountancy 

10 records. 

7. A computer network in accordance with claim 5 or 
claim 6, wherein said input means is arranged to 
permit the input of additional data when data indie- 
's ative of the authorisation of an update of account- 
ancy records is input, wherein said update means 
is arranged to initiate amendments to said account- 
ing records within said computer utilizing said data 
received by said receiving means, and said data in- 

20 put by said input means. 

8. A computer network in accordance with claims 4 to 
7, further comprising association means for associ- 
ating data indicative of amended accountancy 

25 records with additional data, wherein said update 
means is arranged to update records within a com- 
puter utilizing said additional data associated with 
data indicative of amended accountancy records 
via said association means. 

30 

9. Computer apparatus for facilitating the storage and 
amendment of accountancy records indicative of 
reciprocal obligations comprising: 

35 means for storing and amending accountancy 

records each indicative of one side of a recip- 
rocal obligation; and 

monitoring means for monitoring the amend- 
ment of said accounting records within said 
40 computer, said monitoring means being ar- 

ranged to output data indicative of the content 
of amended accountancy records. 

10. Apparatus in accordance with claim 9, further com- 
45 prising: 

receiving means for receiving data indicative of 
the content of amended accountancy records 
stored within other computers of said plurality 

50 of computers; and 

update means arranged to initiate the amend- 
ment of accountancy records within a computer 
utilizing data received by said receiving means 
wherein said update means is arranged to ini- 

55 tiate amendments to accounting records indic- 

ative of the other side of the reciprocal obliga- 
tion to that indicated by data received by said 
receiving means. 
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11. Computer apparatus for facilitating the storage and 
amendment of accountancy records indicative of 
reciprocal obligations comprising: 

means for storing and amending accountancy 
records each indicative of one side of a recip- 
rocal obligation; 

receiving means for receiving from a communi- 
cations network data indicative of the content 
of amended accountancy records stored within 
other computers; and 

update means arranged to initiate the amend- 
ment of accountancy records within a computer 
utilizing data received by said receiving means 
wherein said update means is arranged to ini- 
tiate amendments to accounting records indic- 
ative of the other side of the reciprocal obliga- 
tion to that indicated by data received by said 
receiving means. 

12. Apparatus in accordance with any of claims 10 or 
1 1 , further comprising input means for inputting da- 
ta indicative of authorisation for the update of ac- 
countancy records within said computer, wherein 
said update means is arranged only to initiate the 
amendment of accountancy records following the 
receipt of data indicative of authorisation of an up- 
date input via said input means. 

13. Apparatus in accordance with claim 12. wherein 
said receiving means is arranged upon receipt of 
data indicative of the content of accountancy 
records to retrieve from said means for storing ac- 
countancy records within said computer records 
corresponding to said amended records, said ap- 
paratus further comprising display means for dis- 
playing retrieved records and data indicative of said 
amended accountancy records priorto input of data 
indicative of authorisation of an update of account- 
ancy records via said input means. 

14. Apparatus in accordance with claim 12 or claim 13, 
wherein said input means is arranged to permit the 
input of additional data when data indicative of the 
authorisation of an update of accountancy records 
is input, wherein said update means is arranged to 
initiate amendments to said accounting records 
within said computer utilizing said data received by 
said receiving means, and said data input by said 
input means. 

15. Apparatus in accordance with claims 9 to 1 4, further 
comprising association means for associating data 
indicative of amended accountancy records with 
additional data, wherein said update means is ar- 
ranged to update records within a computer utilizing 
said additional data associated with data indicative 
of amended accountancy records via said associa- 



tion means. 

1 6. A storage medium storing computer implementable 
instructions for generating within a programmable 
5 computer, apparatus in accordance with any of 
claims 9 to 15. 



15 



20 



25 



30 



35 



40 



45 



50 



13 



EP 1 164 519 A2 



ACCOUNTANCY 
SYSTEM 



/ 1 /" 



BANKING 
MODULE 



CONVERSION 
MODULE 



INVOICE 
PROCESSING 
MODULE 



A. 



ACCOUNTANCY 
SYSTEM 



± 



11 



BANKING 
MODULE 



CONVERSION 
MODULE 



INVOICE 
PROCESSING 
MODULE 



I/ 



INVOICE 
DATABASE 



SERVER 
PROCESSING 
MODULE 



REMITTANCE 
DATABASE 



17 



15 



19 



FIG. 1 



14 



EP 1 164 519 A2 



< 



DATABASE MANAGEMENT 



CLIENT DATABASE 



ORDER PROCESSING 



SALES LEDGER 



DEBTORS LEDGER 



PURCHASE LEDGER 



CREDITORS LEDGER 



CASH LEDGER 



•20 
■24 
26 
28 
30 
32 
34 
36 



FIG. 2 



r 

> 


SELLER ORDER ID 


> 


> 


BUYER ORDER NO 


< 




ITEM RECORD 1 






ITEM RECORD n 


J 



40 

■42 

44 



FIG. 3 



15 



EP1 164 519 A2 



INVOICE ID 



DATE DATA 



CLIENT ID 



BUYER ORDER NO 



SELLER ORDER NO 



ITEM RECORD 1 



ITEM RECORD n 



PRICE RECORD 



TEXT DATA 



50 
•52 
•54 
56 
58 

60 



-62 

64 FIG. 4 



16 



EP 1 164 519 A2 




17 



EP 1 164 519 A2 



CO 

O 




o 

DC 



18 



EP 1 164 519 A2 




FIG. 7 



19 



EP1 164 519 A2 



START 



1 


r 


IDENTIFY NEW INVOICES 




r 


CONVERT & DISPATCH TO 
SERVER 




r- 


IDENTIFY NEW PAYMENTS 




r 


CONVERT & DISPATCH TO 
SERVER 




r 



S20 



S21 



S22 



S23 



END 



FIG. 8 



20 



EP1 164 519 A2 



REF NUMBER 



DATE DATA 



BUYER ORDER NO 



SELLER ORDER NO 



BUYER RECORD 



SELLER RECORD 



ITEM RECORD 1 



ITEM RECORD n 



PRICE RECORD 



TEXT DATA 



-110 
•112 
•114 
■116 
•118 
120 

122 

124 

• 126 



FIG. 9 



21 



EP1 164 519 A2 



REF NUMBER 



DATE DATA 



BUYER RECORD 



SELLER RECORD 



INVOICE RECORD 1 



INVOICE RECORD M 



REMITTANCE RECORD 



130 
132 
134 
136 

138 

140 



FIG. 10 



22 



EP1 164 519 A2 



START 



CONVERT INVOICE 
INTO ODBC DATA 



S40 



RETRIEVE & DISPLAY 
ORDER MATCHING 
RECEIVED ODBC 
ORDER ID 



S41 




S46 



NO , 



ERROR HANDLING 



NO 



UPDATE CREDITORS & 
PURCHASE LEDGERS 



S45 



END 



FIG. 11 



23 



EP1 164 519 A2 



START 



I 



CONVERT 
REMITTANCE ADVICE 
INTO ODBC DATA 



S60 



RETRIEVE RECORDS 
CORRESPONDING TO 
ORDER NUMBER 



S62 




S69 



NO 



x— ► 



DISPLAY RECORDS & 
RECEIVED DATA 



S66 




ERROR HANDLING 



UPDATE CREDITORS & 
CASH LEDGERS 



S68 



END 



FIG. 



24 




25 



EP1 164 519 A2 



STATEMENT REQUEST ID 



COMPANY RECORD 



CLIENT RECORD 



TIME PERIOD 



150 
152 
154 
156 



FIG. 14 



26 



EP 1 164 519 A2 




S100 



INVOICE 




S102 



REMITTANCE 




STORE IN 
REMITTANCE 
DATABASE 

] 



DETEf 
DESTIlv 


3MINE 
IATION 




f 


GENERATE & 
OUTPUT MESSAGE 



S104 



S110 



STATEMENT 
REQUEST 



GENERATE & 

OUTPUT 
STATEMENT 



S106 



S107 



END 



FIG. 15 



27 



EP1 164 519 A2 



STATEMENT REQUEST ID 



COMPANY RECORD 



CLIENT RECORD 



INVOICE RECORD 1 



INVOICE RECORD n 



PAYMENT RECORD 1 



PAYMENT RECORD n 




166 



168 



FIG. 16 



28 



